Summary

The renderer-side handler in src/onWalletReady.ts uses error?.constructor.name === 'WERR_REVIEW_ACTIONS' to detect review-actions errors at three sites (createAction, signAction, internalizeAction). The Vite production build (esbuild minification) renames class identifiers, so at runtime constructor.name returns mangled values like 'a' and the check returns false. Errors then fall through to the generic else branch which only emits {message: ...} — dropping code: 5, reviewActionResults, sendWithResults, txid, tx, and noSendChange from the response body.

The calling app's @bsv/sdk HTTPWalletJSON checks data.code === 5 (and matching siblings 6, 7, 8) to reconstruct the proper WERR_REVIEW_ACTIONS instance with the signed transaction and review reasons. Without code: 5 reaching the wire, the SDK falls through to its own generic Error wrapper, leaving the calling app unable to:

• Recover the signed transaction (the tx AtomicBEEF) for fallback broadcast through other providers
• Surface the structured review reason ('serviceError' | 'doubleSpend' | 'invalidTx') to the user
• Distinguish review-actions failures from generic errors

This makes any flow using acceptDelayedBroadcast: false un-debuggable when the bundled broadcaster encounters a review condition.

How discovered

Hit while integrating BRC-100 wallet support in a DEX (BSV-21 mint flow with ~5KB embedded-icon deploy script). With BSV Desktop v2.2.7 the createAction returned 400 with body {"message":"Undelayed createAction or signAction results require review."} — no code, no tx, no reviewActionResults. With MetaNet Desktop on the same flow + script size, the SDK reconstructed WERR_REVIEW_ACTIONS correctly via case 5: dispatch, surfacing the review reason and providing the signed tx for manual fallback broadcast.

Verified the JSON.stringify produces the expected fields when isolated:

```js
const e = new sdk.WERR_REVIEW_ACTIONS([{txid:'a',status:'serviceError'}], [{txid:'a',status:'sending'}], 'a', [1,2,3], ['a.0']);
console.log(JSON.stringify(e));
// {"reviewActionResults":[...],"sendWithResults":[...],"txid":"a","tx":[1,2,3],"noSendChange":["a.0"],"isError":true,"code":5,"name":"WERR_REVIEW_ACTIONS"}
```

So the serialization itself is fine — the bug is the detection check failing under minification, which routes the error to the wrong branch entirely.

Fix

Replace the brittle constructor.name string check with a duck-type predicate matching on the canonical error message + presence of the reviewActionResults array:

```ts
function isWerrReviewActions(error: unknown): error is { reviewActionResults: unknown[] } {
if (typeof error !== 'object' || error === null) return false;
const e = error as { message?: unknown; reviewActionResults?: unknown };
return (
e.message === 'Undelayed createAction or signAction results require review.' &&
Array.isArray(e.reviewActionResults)
);
}
```

This is robust to:

• Bundler class-name minification (esbuild, terser, etc.)
• The cross-package class identity issue: errors are thrown by @bsv/wallet-toolbox's WERR_REVIEW_ACTIONS class but checked here against an import of @bsv/sdk's WERR_REVIEW_ACTIONS class — these are separate class declarations, so instanceof would not work as a replacement either.

The duck-type check fires for both wallet-toolbox-thrown and SDK-thrown errors that genuinely match the WERR_REVIEW_ACTIONS shape, and would not false-positive on unrelated errors (the canonical message string is unique to this error type).

Test plan

• `npm run build` — renderer + electron build clean
• `npm test` — translations test (13 tests passing)
• `npx vitest run --config vitest.config.electron.ts test/onWalletReady.test.ts` — onWalletReady tests (12 tests passing)
• End-to-end manual test: createAction with `acceptDelayedBroadcast: false` and a deploy script that triggers the bundled broadcaster's review path, verify `data.code === 5` reaches the SDK and `case 5:` dispatch reconstructs `WERR_REVIEW_ACTIONS` with the signed `tx` field

🤖 Generated with Claude Code